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UNIVERSAL SECURE REGISTRY 

1. Field of the Invention 

5 This invention relates to a method and apparatus for securely storing and 

disseminating information regarding individuals and, more particularly, to a 
computer system for authenticating identity or verifying the identity of 
individuals and other entities seeking access to certain privileges and for 
selectively granting privileges and providing other services in response to such 
10 identifications/verifications. 

2. Background of the Invention 

Dissemination of information regarding various entities, including 
individuals, in society is conventionally done in a non-centralized fashion, often 

15 requiring specialized knov^ledge of a likely storage location to access the 
information. This specialized knowledge may not be available when the 
information is needed, thus effectively preventing distribution of the information 
when required. For example, a doctor in an emergency room may desire access 
to a patient's medical history in determining a course of treatment. If the person 

20 is not carrying a complete medical record, which is typically the situation, the 
medical records may not be available to the doctor. Even if these medical 
records are available electronically, for example via a computer accessible in the 
person's regular doctor's office, the records may effectively be unavailable if the 
person is unconscious or otherwise incapacitated or if restrictions on access to 

25 the doctor's records cannot otherwise be overcome. The retrieval of required 
medical records can be further complicated by the fact that such records can be 
located at a number of different sites/systems which are not linked. For example, 
the patient's primary care physician may not have records from a specialist 
treating the patient, and none of these physicians may have dental records. 

30 Similar problems arise in other environments where relevant data may be 
scattered and/or otherwise difficult to access. 



Identification of a person from other persons within a society and 
verification of a person as being who he says he is are extremely important for 
many reasons. For example, determination/verification of a person's identity 
will typically dictate extension of credit, granting access to information, 
5 allowing entry to a restricted area, or the granting of numerous other privileges. 

Most people carry multiple forms of identification. For example, a typical 
person may carry an identification card issued by a federal, state, or local 
governmental entity, an identification card issued by a university or place of 
employment, one or more credit cards that serve to identify the person as a 
10 holder of a credit card account, one or more bank cards that serve to identify the 
person as holder of a bank account, medical information cards identifying the 
person as a member of, for example, a health maintenance organization or as a 
person holding an insurance policy from a specified insurance company, keys 
that identify the person as owner of an automobile, house, etc., and numerous 
15 other identification cards that may be used for specialized purposes, such as 

identifying the person as a member of a health club, a library, or a professional 
organization. 

To enable the person to function effectively in society, the person must 
typically have one or more of these identification devices with them if they wish 

20 to undertake an associated activity. For example, a person is not allowed to 

drive a car or purchase alcohol without a governmentally issued driver's license. 
Likewise, although cash may be used to purchase goods and/or services, the 
person will typically not be able to purchase goods and/or services with a credit 
card if the person is not physically carrying the credit card. Similarly, most 

25 hospitals and other medical facilities will require proof of insurance before 

rendering medical attention. Carrying these multifarious identification devices 
can become onerous. Additionally, if one or more of the identification devices is 
lost, stolen or forgotten, it can be inconvenient, making it difficult to obtain 
goods or services requiring the missing identification. 

30 There are also times when the individual may wish to be identified or at 

least verified without providing personal information. For example, a person 
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may wish to purchase goods and/or services without publicly providing his/her 
credit card information for fear that the credit card information be may be stolen 
and used fraudulently. Likewise, the person may wish to purchase goods or 
order goods to be delivered to an address without revealing the address to the 
5 vendor. Unfortunately, conventional identification devices require that at least 
some personal information be transmitted to complete a transaction. 

There are other related problems. For example, when there is a need to 
locate a person or other entity where only limited biographical data is known, 
this can be difficult since relevant information is seldom available from a single 

10 database. Another potential problem is the forwarding of mail, packages, 

telephone calls/messages, e-mails and other items where a party is in a situation 
where they are changing location frequently and/or where the person does not 
want such information to be generally available for security or other reasons. A 
simple, yet secure, way of dealing with such issues does not currently exist. 

15 Another potential problem is filling in forms, particularly for an 

individual who frequently has to complete the same or similar form. Such forms 
can for example be medical forms when visiting a doctor or entering a hospital, 
immigration forms on entering the country, employment forms, college entry 
forms, etc.. It would be desirable if such forms could be completed once and be 

20 available for future use, and it would be even better if the information for each 
such form could be automatically drawn from an existing database to complete 
the form. There is also a frequent requirement to periodically update information 
in a form, for example financial information for a line of credit. It would be 
desirable if such updates could be automatically performed from data in a 

25 general database. 

Still another potential problem is that a person may be forced to make 
requests on a database, for example financial requests, under duress. It would be 
desirable if the person could easily and undetectably signal such duress when 
making the request and the receiving system be able to act appropriately to assist 

30 and protect the individual. 
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Systems capable of effectively performing all of these functions do not 
currently exist. 

5 SUMMARY OF THE INVENTION 

There is thus a need for an identification system that will enable a person 
to be identified or verified ("identification" sometimes being used hereinafter to 
mean either identified or verified) and/or authenticated without necessitating the 
provision of any personal information. Likewise, there is a need for an 

10 identification system that will enable a person to be identified universally 
without requiring the person to carry multiple forms of identification. 

Accordingly, this invention relates, in one embodiment, to an information 
system that may be used as a universal identification system and/or used to 
selectively provide personal, financial or other information about a person to 

15 authorized users. Transactions to and from the database may take place using a 
public key /private key security system to enable users of the system and the 
system itself to encrypt transaction information during the transactions. 
Additionally, the private key/public key security system may be used to allow 
users to validate their identity and/or sign instructions being sent to a universal 

20 secure registry (USR) system of the type to which this invention relates. For 
example, in one embodiment, a smart card such as the Secure ID ™ card from 
RSI Security, Inc. may be provided with the user's private key and the USR 
system's public key to enable the card to encrypt messages being sent to the USR 
system and to decrypt messages from the USR system 10. 

25 This USR system or database may be used to identify the person in many 

situations, and thus may take the place of multiple conventional forms of 
identification. Additionally, the USR system may enable the user's identity to be 
confirmed or verified without providing any identifying information about the 
person to the entity requiring identification. This can be advantageous where the 

30 person suspects that providing identifying information may subject the 
identifying information to usurpation. 
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Enabling anonymous identification facilitates multiple new forms of 
transactions. For example, enabling anonymous identification enables the 
identified person to be telephoned by or receive e-mails from other persons 
without providing the other person with a telephone number or e-mail address, 
5 and will permit this to be accomplished even where there are frequent changes in 
the persons location.. Similarly, enabling anonymous identification will enable 
the person to receive mail, other delivered parcels and other items without 
providing the recipient's address information to the sender. By restricting access 
to particular classes of persons/entities, the person can effectively prevent 

10 receipt of junk mail, other unsolicited mail, telemarketing calls and the like. 

In a financial context, providing anonymous identification of a person 
enables the person to purchase goods and/or services from a merchant without 
ever transmitting to the merchant information, such as the person's credit card 
number, or even the persons name, that could be intercepted and/or usurped and 

15 used in subsequent or additional unauthorized transactions or for other undesired 
purposes. Enabling anonymous identification may be particularly advantageous 
in an unsecured environment, such as the Internet, where it has been found to be 
relatively trivial to intercept such credit card information. 

In a medical context, the USR system, in addition to enabling a person 

20 seeking medical treatment to identify themselves, may be configured to provide 
insurance data, medical history data, and other appropriate medical information 
to a medical provider, once that medical provider has been established as an 
authorized recipient. The USR system may also contain links to other databases 
containing portions of the patients medical records, for example x-rays, MRI 

25 pictures, dental records, glasses, prescriptions, etc. 

Access to the USR system may be by smart card, such as a Secure ID™ 
card, or any other secure access device. The technology enabling the USR 
system may be physically embodied as a separate identification device such as a 
smart ID card, or may be incorporated into another electronic device, such as a 

30 cell phone, pager, wrist watch, computer, personal digital assistant such as a 
Palm Pilot™, key fob, or other commonly available electronic device. The 
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identity of the user possessing the identifying device may be verified at the point 
of use via any combination of a memorized PIN number or code, biometric 
identification such as a fingerprint, voice print, signature, iris or facial scan, or 
DNA analysis, or any other method of identifying the person possessing the 
5 device. If desired, the identifying device may also be provided with a picture of 
the person authorized to use the device to enhance security. 

The USR system may be useful for numerous other identification 
purposes. For example, the USR anonymous identification may serve as a 
library card, a phone card, a health club card, a professional association 
10 menibership card, a parking access card, a key for access to ones home, office, 
car, etc. or any one of a host of similar identification/verification and/or access 
functions. Additionally, equipment code information may be stored in the USR 
system and distributed under the user's control and at the user's discretion, to 
maintain personal property or public property in an operative state. 

15 

BRIEF DESCRIPTION OF THE FIGURES 

This invention is pointed out with particularity in the appended claims. The 
above and further advantages of this invention may be better understood by referring to 
the following description when taken in conjunction with the accompanying drawings. 
20 The accompanying drawings are not intended to be drawn to scale. In the drawings, each 
identical or nearly identical component that is illustrated in various figures is represented 
by a like numeral. For purposes of clarity, not every component may be labeled in every 
drawing. In the drawings: 

Fig. 1 is a functional block diagram of a computer system configured to 
25 implement the universal secure registry ("USR"), including a USR database, according to 
one embodiment of the invention; 

Fig. 2 is a functional block diagram of a first embodiment of a networked 
environment including the computer system of Fig. 1; 

Fig. 3 is a functional block diagram of an entry of a database forming the USR 
30 database of Fig. 1 



Fig. 4 is a functional block diagram of a second embodiment of a networked 
environment including the computer system of Fig. 1; 

Fig. 5 is a flow chart illustrating steps in a process of inputting data into the USR 
database; 

5 Fig. 6 is a flow chart illustrating steps in a process of retrieving data from the 

USR database; 

Fig. 7 is a flow chart illustrating a first protocol for purchasing goods from a 
merchant via the USR database without transmitting credit card information to the 
merchant; 

10 Fig. 8 is a flow chart illustrating a second protocol for purchasing goods from a 

merchant via the USR database without transmitting credit card information to the 
merchant; 

Fig. 9 is a flow chart illustrating a protocol for purchasing goods from a merchant 
via the USR database by validating the user's check; 
1 5 Fig. 1 0 is a flow chart illustrating a protocol for purchasing goods from an on-line 

merchant via the USR database without transmitting credit card information to the on-line 
merchant, and enabling the on-Hne merchant to ship the goods to a virtual address; 

Fig. 1 1 is a flow chart illustrating a protocol for shipping goods to a virtual 
address via the USR database; 
20 Fig. 12 is a flow chart illustrating a protocol for telephoning a virtual phone 

number via the USR database; 

Fig. 13 is a flow chart illustrating a protocol for identifying a person via the USR 
database; 

Fig. 14 is a flow chart illustrating a protocol for identifying a person to a 
25 policeman via the USR database; 

Fig. 15 is a flow chart illustrating a protocol for providing information to an 
authorized recipient of the information via the USR database; 

Fig. 16 is a flow chart illustrating a protocol for providing application information 
to an authorized recipient of the information via the USR database; and 
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Fig. 1 7 is a functional block diagram of an embodiment configured to use 
information in the USR system to activate or keep active property secured through the 
USR system. 



5 DETAILED DESCRIPTION OF THE INVENTION 

In one embodiment, an information system is formed as a computer program 
running on a computer or group of computers configured to provide a universal secure 
registry (USR) system. The computer, in this instance, may be configured to run 
autonomously (without the intervention of a human operator), or may require intervention 

10 or approval for all, a selected subset, or particular classes of transactions. The invention 
is not limited to the disclosed embodiments, and may take on many different forms 
depending on the particular requirements of the information system, the type of 
information being exchanged, and the type of computer equipment employed. An 
information system according to this invention, may optionally, but need not necessarily, 

1 5 perform fimctions additional to those described herein, and the invention is not limited to 
a computer system performing solely the described functions. 

In the embodiment shown in Fig. 1, a computer system 10 for implementing a 
USR system according to the invention includes at least one main unit 12 connected to a 
wide area network, such as the Internet, via a communications port 14. The main unit 12 

20 may include one or more processors (CPU 16) nmning USR software 18 configured to 
implement the USR system functionality discussed in greater detail below. The CPU 16 
may be connected to a memory system including one or more memory devices, such as a 
random access memory system RAM 20, a read only memory system ROM 22, and one 
or more databases 24. In the illustrated embodiment, the database 24 contains a universal 

25 secure registry database. The invention is not limited to this particular manner of storing 
the USR database. Rather, the USR database may be included in any aspect of the 
memory system, such as in RAM 20, ROM 22 or disc and may also be separately stored 
on one or more dedicated data servers. 

The computer system may be a general purpose computer system which is 

30 programmable using a computer programming language, such as C, C++, Java, or other 
language, such as a scripting language or even assembly language. The computer system 



may also be specially programmed, special purpose hardware, an application specific 
integrated circuit (ASIC) or a hybrid system including both special purpose components 
and programmed general purpose components.. 

In a general purpose computer system, the processor is typically a commercially 
5 available microprocessor, such as Pentixim series processor available from Intel, or other 
similar commercially available device. Such a microprocessor executes a program called 
an operating system, such as UNIX, Linux, Windows NT, Windows 95, 98, or 2000, or 
any other commercially available operating system, which controls the execution of other 
computer programs and provides scheduling, debugging, input/output control, 

10 accounting, compilation, storage assignment, data management, memory management, 
communication control and related services, and many other functions. The processor 
and operating system defines a computer platform for which application programs in 
high-level programming languages are written. 

The database 24 may be any kind of database, including a relational database, 

15 object-oriented database, unstructured database, or other database. Example relational 
databases include Oracle 81 from Oracle Corporation of Redwood City, California; 
Informix Dynamic Server from Informix Software, Inc. of Menlo Park, California; DB2 
from International Business Machines of Armonlc, New York; and Access from 
Microsoft Corporation of Redmond, Washington. An example object-oriented database 

20 is ObjectStore from Object Design of Burlington, Massachusetts. An example of an 
unstructured database is Notes from the Lotus Corporation, of Cambridge, 
Massachusetts. A database also may be constructed using a flat file system, for example 
by using files with character-delimited fields, such as in early versions of dBASE, now 
known as Visual dBASE from Inprise Corp. of Scotts Valley, California, formerly 

25 Borland International Corp. 

The main unit 12 may optionally include or be connected to an user interface 26 
containing, for example, one or more input and output devices to enable an operator to 
interface with the USR system 10. Illustrative input devices include a keyboard, keypad, 
track ball, mouse, pen and tablet, communication device, and data input devices such as 

30 voice and other audio and video capture devices. Illustrative output devices include 
cathode ray tube (CRT) displays, liquid crystal displays (LCD) and other video output 
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devices, printers, communication devices such as modems, storage devices such as a disk 
or tape, and audio or video output devices. Optionally, the user interface 26 may be 
omitted, in which case the operator may communicate with the USR system 10 in a 
networked fashion via the communication port 14. It should be understood that the 
5 invention is not limited to any particular manner of interfacing an operator with the USR 
system. 

It also should be understood that the invention is not limited to a particular 
computer platform, particular processor, or particular high-level programming language. 
Additionally, the computer system may be multiprocessor computer system or may 

10 include multiple computers cormected over a computer network. It further should be 
understood that each module or step shown in the accompanying figures and the substeps 
or subparts shown in the remaining figures may correspond to separate modules of a 
computer program, or may be separate computer programs. Such modules may be 
operable on separate computers. The data produced by these components may be stored 

15 in a memory system or transmitted between computer systems. 

Such a system may be implemented in software, hardware, or firmware, or any 
combination thereof The various elements of the information system disclosed herein, 
either individually or in combination, may be implemented as a computer program 
product, such as USR software 18, tangibly embodied in a machine-readable storage 

20 device for execution by the computer processor 16. Various steps of the process may be 
performed by the computer processor 16 executing the program 18 tangibly embodied on 
a computer-readable mediiim to perform functions by operating on input and generating 
output. Computer programming languages suitable for implementing such a system 
include procedural programming languages, object-oriented programming languages, and 

25 combinations of the two. 

As shown in Fig. 2, the computer system 10 may be connected to a plurality of 
interface centers 27 over a wide area network 28. The wide area network 28 may be 
formed from a plurality of dedicated connections between the interface centers 27 and the 
computer system 10, or may take place, in whole or in part, over a public network such as 

30 the Internet. Communication between the interface centers 27 and the computer system 
10 may take place according to any protocol, such as TCP/IP, ftp, OFX, or XML, and 



-10- 



may include any desired level of interaction between the interface centers 27 and the 
computer system 10. To enhance security, especially where communication takes place 
over a publicly accessible network such as the Internet, communications facilitating or 
relating to transmission of data from/to the USR database 24 or the computer system 10 
5 may be encrypted using an encryption algorithm, such as PGP, DES, or other 
conventional symmetric or asymmetric encryption algorithm. 

In one embodiment, the USR system 10 or USR database 24 may be able to 
authenticate its identity to a user or other entity accessing the system by providing an 
appropriate code which may be displayed on the user's smart card, for example a 
10 SecurlD™ card or its equivalent, or other code generator, for example a single use code 
generator, being employed by the user. A comparison by the user or the code generator 
between the provided number and an expected number can validate, to the user (or other 
entity) or the code generator, that communication is with the database and not an 
imposter. 

1 5 The database 24 shown in Fig. 1 has a USR database containing entries related to 

persons 1-n. The data in the USR database may also be segregated, as shown in Fig. 4, 
according to data type to enable individual computer modules to handle discrete 
applications on discrete data types. Segregating the data, as illustrated in Fig. 4, may 
make access to the database more robust by enabling portions of the data in the USR 

20 database 24 to be accessible even when it is necessary to perform maintenance on a 

portion of the database. However, storing the data in the USR database 24 according to 
the scheme illustrated in Fig. 1 may make it easier for a user of the database to make 
changes to multiple types of data simultaneously or in a single session. There are 
advantages and disadvantages to each data structure, and the invention is not limited to a 

25 particular manner of organizing the data within the database 24, data structures other than 
the two shown also being possible. 

As shown in Fig. 3, each entry 30 in the database 24 may contain multiple types 
of information. For example, in the embodiment shown in Fig. 3, the entry contains 
validation information 32, access information 34, publicly available information 36, 

30 address information 3 8, credit card and other financial information 40, medical 

information 42, job application information 44, and tax information 46. The invention is 
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not limited to a USR containing entries with all of this information or only this particular 
information, as any information on a person or other entity such as a company, 
institution, etc. may be stored in USR database 24. 

If the database information is split between multiple databases, each database will 
typically include at least the validation and access information to enable the USR 
software to correlate a validation attempt with a verified validation, and to enable the 
USR software to determine access privileges to the requested data. Alternatively, 
databases may be linked to permit information not in a main USR database to be 
retrieved, with validation/identification for all databases accessed being done at the USR 
system. 

In Fig. 3, the validation information is information about the user of the database 
to whom the data pertains and is to be used by the USR software 18 to validate that the 
person attempting to access the information is the person to whom the data pertains or is 
otherwise authorized to receive it.. The validation information may be any type of 
information that will reliably authenticate the identity of the individual. 

In one embodiment, the user of the database will carry a SecurlD™ card available 
from RSA Security, formerly Security Dynamics Technologies, Inc., of Cambridge, MA. 
Use of this card enables secure access to the USR database without requiring the user to 
transmit any personal information. Specifically, to access the USR database, the card 
retrieves a secret user code and/or time varying value from memory and obtains from the 
user a secret personal identification code. The card mathematically combines these three 
numbers using a predetermined algorithm to generate a one-time nonpredictable code 
which is transmitted to a the computer system 10. The computer system, specifically 
USR software 18, utilizes the received one-time nonpredictable code to determine if the 
user is authorized access to the USR database and grants access to the USR database if 
the user is determined to be authorized. The verification information 32 in the database 
entry in the embodiment of the invention illustrated in Fig. 3 contains information to 
enable the USR software 1 8 to validate the user using such a card in this manner. 

Alternative types of identification cards or tokens may likewise be used. For 
example, other smart cards may be used which generate non-predictable single use codes, 
which may or may not be time varying, or other access code generators may be used. An 
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algorithm generating such non-predictable codes may also be programmed onto a 
processor on a smart card or other computing device, such as a cell phone, pager, ID 
badge, wrist watch, computer, personal digital assistant, key fob, or other 
commonly available electronic device. For convenience, the term "electronic ID 
5 device" will be used generically to refer to any type of electronic device that may 
be used to obtain access to the USR database. 

Likewise, various types of biometric information may be stored in the verification 
area of the database entry to enable the identity of the user possessing the identifying 
device to be verified at the point of use. Examples of the type of biometric information 

1 0 that may be used in this situation includes a personal identification number (PIN), 

fingerprint, voice print, signature, iris or facial scan, or DNA analysis. If desired, the 
verifying section of the database may contain a picture to be transmitted back to the 
person seeking to validate the device to ensure the person using the device is the correct 
person. Optionally, the identifying device itself may also be provided with a picture of 

1 5 the person authorized to use the card to provide a facial confirmation of the person's right 
to use the card. 

In Fig. 3, the Access information 34 is provided to enable different levels of 
security to attach to different types of information stored in the entry 30 in the USR 
database 14. For example, the person may desire that their address information be made 

20 available only to certain classes of people, for example colleagues, friends, family. 

Federal Express, U.P.S., and the U.S. mail service. The names or universal identifiers for 
those selected individuals, companies, organizations and/or agencies may be entered into 
appropriate fields in the Access information to specify to the USR software 1 8 those 
individuals to whom the address information may be released. Likewise, access fields 

25 may be specified for the other types of information. For example, the individual may 
specify that only particular individuals and/or companies have access to the credit card 
and other financial information 40, medical information 42, job application information 
44 and tax information 46. Additionally, the individual may specify that no one have 
access to that information unless the individual participates in the transaction (see Fig. 6). 

30 As shown in Fig. 1, the USR software 18 contains algorithms for execution by the 

CPU 16 that enables the CPU 16 to perform the methods and functions of the USR 
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software described below in connection with Figs. 5-16. The USR software 1 8, in this 
embodiment, performs all fimctions associated with validating an electronic ID card. If 
desired, a separate validation software module may be provided to validate electronic ID 
devices outside of a firewall segregating the validation information from other user 
5 information. 

This algorithms comprising the USR software 18 may be used to implement, in 
one exemplary embodiment, a USR system configured to enable selected information to 
be disseminated to selected individuals in a secure and dynamic fashion. This 
information may be used for numerous purposes, several of which are set forth below and 

10 discussed in greater detail in connection with Figs. 5-16. 

For example, the USR system may be used to identify the person, enable the 
person to be contacted by telephone or mail anonymously, enable the person to be 
contacted by telephone or by mail without revealing the person's telephone number or 
present location, enable the person to purchase items over the Internet or in a store 

1 5 without revealing to the merchant any personal identification information or credit card 
information, enable the person to complete a job application without completing a job 
application form, enable the police to discern the person's identity and any outstanding 
warrants on the individual, and numerous other uses. The invention is not limited to 
these several enumerated uses, but rather extends to any use of the USR database. The 

20 methods of using the USR database 24 will now be discussed in connection with Figs. 5- 
16. 

Fig. 5 illustrates a method of training the USR database 24. As shown in Fig. 5, 
the USR software 1 8 first validates the person' s identification (5 00). The initial 
validation of the person's identification (500) may take place at the point of sale of an 

25 electronic ID device (for example, a smart card). This may be done in any conventional 
manner, such as by requiring the person to show a government issued identification card, 
passport, birth certificate, etc. Once the person's electronic ID device has been issued 
and initially validated, the validation process proceeds as discussed above. 

After the validation process (500), the USR software 1 8 determines if the person 

30 has rights to enter data into the system (502). This step enables the system to charge 
persons for maintaining information in the USR database 24. For example, the USR 
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software 1 8 may poll a database of current accounts or a database of accounts that are 
currently in default to determine if the person has paid the access fee to enter data into the 
database. A similar account status inquiry process may be performed by the USR 
software 1 8 in connection with each of the other methods set forth in Figs. 6-16. If the 
5 person is not authorized to enter data into the USR database 24, the person is notified of 
the status of their account and the process returns (512) to wait for ftirther input from 
another person. Alternatively, a person may be permitted to enter some classes of data 
into the system and update such classes of data at no charge, with a fee possibly being 
required for other classes of data, for example medical records. This would facilitate a 

10 more robust database. 

If the person is authorized, the USR software 18 then enables the person to enter 
basic personal data into the USR database 24 (504). Optionally, personal data may be 
one class of data the USR software 1 8 allows the person to enter into the USR database 
18 regardless of account status, i.e., for free. 

1 5 The USR software 1 8 will then check to see if the person has additional rights to 

enter additional data (506), such as data to be entered into one of the other categories of 
data in Fig. 3 . Optionally, this step of checking the person's rights to enter data (506) 
may be combined with the initial check (502). If the person does not have rights to enter 
any further data, the USR software 1 8 notifies the user and returns (512). 

20 If the USR software 1 8 determines that the person has the right to enter additional 

data into the USR database 24, the person is prompted through the use of appropriate 
prompts, provided v^th forms, and otherwise enabled to enter advanced personal data 
into the USR database 24 (508). For each type of data entered, the person is asked to 
specify the type of access restrictions and/or whom should be allowed to access the 

25 advanced personal data (510). When the person has completed entering data into the 
database, the process returns (512) and commits the data to the database. 

In the situation where only one person has access to enter and/or modify data for a 
given person in the database, there should be no conflict with committing data to the 
database. If, however, multiple people have access to a given account to modify data, the 

30 database may perform an integrity check to ensure the absence of conflict in the data 
before committing the new data to the database. 
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Enabling access to the information in the database will be explained in greater 
detail in connection with Fig. 6. As shown in Fig. 6, the database will generally allow 
anyone to access basic personal data on anyone without performing any authorization 
check (600). 

5 If information beyond that specified in the basic personal information area is 

requested, the USR software 18 queries whether the requestor has the right to access the 
type of requested data (602). The process of determining the requestors rights (602) 
typically involves validating the requestor's identity and correlating the identity, the 
requested information and the access information 34 provided by the person to the USR 

10 database during the training process described above with respect to Fig. 5. 

If the USR software 18 determines that the requestor has rights to access the type 
of requested data (604), the USR software 1 8 instructs the USR database 24 to enable 
access to the type of requested data (606). The actual step of enabling access to the type 
of requested data may involve multiple steps of formulating a database query, querying 

15 the USR database 24, retrieving the results, assembling the results into a user friendly or 
user readable format, and transmitting the information to the user. 

If the USR software 18 determines that the requestor does not have the 
appropriate rights to access the type of requested data (604), the USR software 18 checks 
to see if the person is participating in the transaction (608). Checking to see if the person 

20 is participating in the transaction enables the user to authorize access to the requested 

data in real time. For example, a person may wish to participate in a transaction to give a 
potential employer one-time access to job application information 44 (see Fig. 3). If the 
person is not participating in the transaction, the USR software 1 8 determines that the 
requestor is not authorized to have access to the requested data, notifies the requestor of 

25 this determination, and ends (610). 

If the person is participating in the transaction (608), however, the USR software 
18 validates the person's identity (612) and enables the person to change access rights to 
the data (614). If the USR software 18 is not able to validate the person's identity, the 
USR software 1 8 refuses to allow the person to update the database, notifies the person 

30 and/or requestor of this determination, and returns (610). 
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It is also possible that a person may be required to grant access to certain data, for 
example financial data such as account numbers, under duress. The system may provide 
the person with the ability to safely signal this when accessing the system by using a 
selected access code or by making a known modification to the access code provided by 
5 the electronic ID device. On receiving such code, the system would take appropriate 
steps to protect the person, including for example alerting the police, tracking the 
person's location to the extent possible, providing traceable data, and the like. 

Once the person has had the opportunity to change access rights to the data (614), 
the USR software 1 8 again checks to see if the requestor has rights to access the type of 

1 0 requested data (616). Although step 6 1 6 may seem redundant, given the fact that the 

person is participating in the transaction and has just previously changed access rights to 
the database to enable the requestor to have access to the data, step 616 is actually useful 
at preventing a different type of fraud. Specifically, the requestor may not be forthright 
with the person regarding the type of information they are requesting. If step 616 were 

1 5 omitted, the USR software 1 8 may inadvertently allow access to an unauthorized type of 
information in the situation where the requestor has surreptitiously requested multiple 
types of data. 

If the USR software 1 8 determines that the requestor has rights to the type of data 
requested (616), it causes the USR database to enable access to the type of requested data 
20 (606). Otherwise, it notifies the requestor of the decision to deny access to the requested 
data and returns (610). 

Various applications of the USR database 24 and USR software 18 will now be 
discussed in cormection with Figs. 7-16. These applications are merely exemplary of the 
types of applications enabled by the USR software 18 and USR database 24, and the 
25 invention is not limited to these particular applications. 

Figure 7 illustrates one embodiment of a method of using the USR software 1 8 
and USR database 24 to purchase goods or services from a merchant without revealing to 
the merchant account information relating to the person's bank or credit card. 

As shown in Fig. 7, when a user initiates a purchase (700), the user enters a secret 
30 code in the user's electronic ID device (702) to cause the ID device to generate a one- 
time code or other appropriate code, and presents the electronic ID device with the code 
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to the merchant or otherwise presents the code to the merchant. The merchant transmits 
to the credit card company (1) the code from the electronic ID device, (2) the store 
number, (3) the amount of the purchase (704), and the time of receipt of the code. The 
credit card company takes this information and passes the code from the electronic ID 
5 device to the USR software 1 8 (706). The USR software 18 determines if the code is 
valid, or was valid at the time offered, and if valid accesses the user's credit card 
information and transmits the appropriate credit card number to the credit card company 
(708). While the link between the USR system and the credit card system is a secure 
link, there is always a danger that the link may be penetrated and credit card numbers 

10 obtained. This may be avoided by instead transmitting, on approval, a multidigit public 
ID code for the credit card holder which the credit card company can map to the correct 
credit card number. Even if the link is violated, the public ID code is of no value and the 
secure link prevents this code from being improperly sent to the credit card company. 
The credit card company checks the credit worthiness of the user and declines the card or 

15 debits the user's account in accordance with its standard transaction processing system 
(710). The credit card company then notifies the merchant of the result of the transaction 
(712). In this embodiment, the user has been able to purchase goods or services from a 
merchant without ever providing to the merchant the credit card nizmber. Since the 
electronic ID device generates a time variant code or otherwise generates a code that can 

20 for example only be used for a single transaction, the merchant retains no information 
from the transaction that may be fraudulently used in subsequent transactions. 

Another embodiment of a system for facilitating purchase of goods or services 
without providing financial information to the merchant is set forth in Fig. 8. In Fig. 8, 
like Fig. 7, the user initiates a purchase (800), enters a secret code in the electronic ID 

25 device (802) and presents the resultant code to the merchant. The merchant, in this 

embodiment, transmits to the USR software 18, (1) the code from the electronic ID, (2) 
the store number, and (3) the amount of the purchase (804). The USR software 18 
determines if the code is valid (806) and, if valid, accesses from the USR database 24 the 
user's credit card information (808). The USR software then transmits to the credit card 

30 company (1) the credit card number, (2) the store number, and (3) the amount of purchase 
(808). The information in this embodiment transmitted to the credit card company is 
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intended to be in a format recognizable to the credit card company. Accordingly, the 
invention is not hmited to transferring from the USR system 1 0 to the credit card 
company the enumerated information, but rather encompasses any transfer of information 
that will enable the use of the USR system 10 to appear transparent to the credit card 
5 company. 

The credit card company then processes the transaction in a standard fashion, 
such as by checking the credit worthiness of the person, declining the card or debiting the 
user's account and transferring money to the merchant's account (810). The credit card 
company then notifies the USR system 10 the result of the transaction (812) and the USR 

1 0 software 1 8 in turn notifies the merchant of the result of the transaction (814). 

In this embodiment, like the embodiment of Fig. 7, the user can use the USR 
system 10 to purchase goods or services from a merchant without providing the merchant 
with the user's credit card number. In the embodiment of Fig. 8, the interposition of the 
USR system 1 0 between the merchant and the credit card company is transparent to the 

1 5 credit card company and thus requires no or minimal cooperation from the credit card 
company to implement. 

Fig. 9 illustrates one embodiment of a method of using the USR system 10 to 
verify funds when using a check to purchase goods or services from a merchant. In the 
embodiment of Fig. 9, the user initiates a purchase and writes a check to the merchant 

20 (900). The check may be a conventional check containing identifying information, or 
may be a check bearing a unique serial number and no identifying information to enable 
the check to be used anonymously. 

In either situation, the user enters a secret code into the electronic ID card and 
presents the resulting code to the merchant along with the check (902). The merchant 

25 transmits to the USR software 18 (1) the code from the electronic ID card, (2) the store 
number, and (3) the amount of the purchase (904). Where the check is an anonymous 
check, the merchant also transmits to the USR software 1 8 the check number. 

The USR software 1 8 then determines if the code from the electronic ID is valid 
(906), and if valid accesses the user's bank information and transmits to the bank: (1) the 

30 user's bank account number, (2) the store number, and (3) the amount of the purchase. 
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(908). Optionally, the USR software 1 8 may additionally inform the bank of the check 
number. 

The bank polls its own database to determine if there are sufficient funds in the 
user's account (910) and notifies the USR software 18 of the result (912). The USR 
5 software 1 8 then, in turn, notifies the merchant of the result of the verification (914). 

This check verification system may take place over an unsecured connection 
between the merchant and the USR system 10 since the user's bank account information 
is not sent over the connection between the merchant and the USR system 1 0. Moreover, 
where an anonymous check is used, the merchant is not even provided with the person's 
10 name or account information in written form. This provides additional security against 
unauthorized persons writing subsequent checks. 

The check verification system may be conducted over a telephone network, such 
as by having the merchant call a toll free number, or over a network connection such as 
over the Internet. 

1 5 Fig. 1 0 illustrates a method of conducting a transaction with a merchant without 

requiring the user to provide to the merchant the user's name, address, or other 
identifying information, while enabling the merchant to ship the goods to the user. This 
may be beneficially employed, for example, in connection with transactions that take 
place between remote parties in a networked environment, such as the Internet. 

20 As shown in Fig. 10, the user initiates an anonymous purchase by entering a 

secret code into the electronic ID device and transmitting the result to the on-line 
merchant (1000). The merchant transmits this information to the USR software 18, along 
with the store number and the amount of the purchase (1002). Optionally, the merchant 
may provide the store number and purchase price to the user and the user may send this 

25 information directly to the USR software 18 along with the code from the electronic ID. 
Where the nimiber from the electronic ID device is a time varying number, the merchant 
may also need to input the time the number was received. Alternatively, the electronic 
ID device may encode or encript the time with the number, the USR software being able 
to extract time when receiving the number from the merchant. This may not be required 

30 where the time varying number varies slowly, for example changing every hour rather 
then every minute as for some existing such devices. 
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In either event, the USR software 18 determines if the code is valid (1004) and, if 
valid, accesses the user's credit card information from the USR database 24 (1006). The 
USR software 18 then contacts the user's credit card company, as described above in 
connection with Fig. 8 (1008) and notifies the USR software 18 of the result (1000). 
5 If the user's credit is declined, the USR software 18 notifies the on-line merchant 

and the transaction is terminated (1012). If the user's credit is honored, the USR 
software 18 polls the USR database 24 for the user's address and/or address code (1014). 
Address codes are discussed below in greater detail with reference to Fig. 1 1 . The 
merchant then packages the goods into a parcel, labels the parcel with the appropriate 

1 0 address and/or address code and ships the parcel to the user (1016). Having the USR 
system 10 provide the address and/or address code to the on-line merchant enables the 
user to purchase items in a networked environment without requiring the user to input 
address information in connection with every sale. 

Fig. 1 1 illustrates an use of the USR database 24 to deliver mail to a user without 

1 5 requiring the user to provide address information to the sender. This may be useful in 
many contexts. For example, the user may wish that the address information be known 
only by the post office. In this instance, using the USR database 24 according to the 
method of the invention described below, will enable the user to receive parcels without 
requiring the user to provide the merchant with the address information. Additionally, 

20 the user's address may change, temporarily, permanently, or frequently. Enabling the 
sender to send mail by entering a code instead of an address enables the post office to 
effectively deliver the coded mail to the corresponding address regardless of the 
frequency with which the address changes or the duration in which the address will 
remain valid. 

25 In Fig. 1 1 , the user provides an address code on a public area of the USR database 

24 that is available to all persons to see (1 100). This code may for example be six alpha 
characters, which should be adequate for currently anticipated system populations. 
Optionally, the user may provide this code directly to a merchant or other person desirous 
of sending the person one or more parcels. 

30 The user also provides address information to the address information area 38 of 

the user's entry in the USR database 24 (1 102). Access to the address information 38 is 
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restricted by a rule or other appropriate entry in the access information 34 of the user's 
entry to only permit mail, parcel or other material delivery services, such as the US mail, 
UPS and Fed Ex to access the address information. 

When someone wishes to have a parcel or other items delivered to the user, the 
5 sender retrieves the user's address code from the USR database 24 or otherwise receives 
the address code from the user, and prints the address code on the parcel (1 104). 

The delivery service accesses the USR software 1 8, validates its identity, and 
queries the USR database 24 for address information corresponding to the address code 
(1 106). The USR database 24 retrieves the appropriate address data and provides the 

10 address information to the delivery service. The delivery service then either prints out an 
address label, prints a machine readable bar code to be attached to the package, or 
correlates an entry in a delivery database between the address code and the user address 
(1 1 1 0). The delivery service then uses this retrieved information to deliver the package 
to the user while never supplying the merchant with the user's permanent or temporary 

15 address. A user may also assure that mail, parcels, etc. are delivered to a current location 
by providing only a single notice to the USR system, regardless of how frequently the 
person moves. The person can also automatically provide for address changes where the 
person moves according to a loiown schedule. Thus, deliveries to be made on a weekday 
could be directed to one address and deliveries on a weekend to another address; or 

20 deliveries during winter months to one address and during summer months to a different 
address. 

Fig. 12 illustrates a method of enabling a person to telephone a user of the USR 
system 10 without providing the user's telephone number to the person. In the 
embodiment illustrated in Fig. 12, the user provides a telephone code on the publicly 
25 available area of his entry on the USR database 24 (1200). This code may be assigned by 
the USR software 18 or made up by the user. The user also provides the USR database 
24 with actual telephone information to enable the USR system 10 to connect callers with 
the user (1202). 

The person wishing to telephone the user of the USR system 10 calls a telephone 
30 number and enters the telephone code of the user (1204). The USR software 18, 

optionally, may require the person to identify themselves to see if they are authorized to 
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call the user. Assuming that the person is authorized to call the person, or if no 
authorization check is performed, the USR connects the person to the telephone number 
in the USR database 24 without providing the person with the telephone number. 

Enabling the user to specify the telephone number may be advantageous for many 
5 reasons. First, the user may frequently be switching between telephone coverage areas 
and may wish to be reachable at all times. Simply by instructing the USR database 24 to 
connect incoming telephone calls to one of a myriad of numbers will facilitate connecting 
the incoming calls to, for example, the user's cell phone, work phone, pager, car phone or 
home phone, without necessitating the user to provide all these numbers to the caller. A 
10 similar system may be implemented for facsimile transmissions, e-mails or other 
communications. 

The user also may have predefined rules to enable telephone calls to follow a set 
pattern. For example, the user may desire to receive telephone calls only from family 
members during the night time at home, may wish to have all incoming calls routed to a 
1 5 car phone during commuting hours, and may wish to have all incoming calls routed to a 
cell phone during lunch. These time dependent rules may and/or caller specific rules may 
be entered into the USR database to specify accessibility and connectivity of incoming 
telephone calls. 

The publicly available address code and telephone code and any other codes may 
20 be the same, or may be different, there being some advantages to having a single code 
usable for all such applications for each person on the system. The codes could be 
accessible through a variety of media including telephone and the internet. Where two or 
more people on the system have the same name, which will frequently be the case, 
additional publicly available biographical data may be provided with the name to assure 
25 that the right code is selected. The system may similarly be used to provide public keys 

for use in a public key /private key encryption system, to provide other public codes for an 
individual or to provide other public information. Access to such information would 
typically be unrestricted. 

Where the system is used to provide public keys, the public code used to obtain 
30 the key, or possibly the public key itself, may be used as above to obtain the e-mail 

address, telephone number or the like for the person to whom the message is being sent, 
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and the USR system may also be used to perform the encryption. When the recipient 
receives the message, he deencrypts it using the recipient's private key in standard 
fashion, including deencrypting the name of the sender. However, this does not 
necessarily verify the sender and such verification may be desirable for important 
5 messages, particularly ones involving large financial transactions. The USR system may 
accomplish such verification by also storing private keys for people in the system. The 
sender first authenticates himself to the system, and the system then adds a second 
signature to the message which is encrypted with the sender's private key. The receiving 
party deencrypts this signature with the sender's public key. Since the system only sends 

1 0 such signatures for authenticated users, the message is thus verified. 

Fig. 13 illustrates a general method of using the USR database 24 to authenticate 
a user's identification. This may be used in connection with any of the other methods 
disclosed herein to ensure that the electronic ID device has not been stolen and/or hacked 
by an imauthorized holder. 

1 5 Specifically, in the embodiment illustrated in Fig. 1 3, the user attempts to prove 

identification to a validator, such as to prove that the possessor of the electronic ID 
device is of sufficient age to purchase alcohol (1300). In connection with this attempt, 
the user enters a secret code into the electronic ID (1302). The validator transmits to the 
USR software 18 the code from the electronic ID (1304). If the USR software 18 

20 determines that the code is valid (1306), it accesses the user's photograph, age 

information, or any other desired information, and transmits that information to the 
validator (1308). By transmitting back to the validator a picture of the person to whom 
the electronic ID card was issued, the validator can ensxire that the person using the 
electronic ID card is the proper person. Likewise, the validator can ensure, based on the 

25 information provided by the USR system 10, that the person is as old as the person claims 
to be. 

A specific embodiment of this identification validation procedure is illustrated in 
Fig. 14. In Fig. 14, a policeman takes the place of the validator. In this scenario, 
however, instead of simply transmitting to the pohceman a validation of the user's 
30 identity, such as their picture, the policeman may also receive additional information, 
such as the user's police records, records of any arrests, outstanding warrants, and other 
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similar information that may be of use to the policeman when determining how to handle 
a particular individual. 

Fig. 15 illustrates a process for enabling the user to provide specific information 
to a party, such as medical staff in an emergency room. As shown in Fig. 15, if the user 
desires to provide information to a party (1500), the user enters a secret code in the 
electronic ID device and provides the electronic ID code to the party (1502). The party 
transmits to the USR software 18 the ID code and the party code (1504). The party code 
may be a code from for example an electronic device which identifies the party, may be a 
status code which identifies the class of users to which the party belongs, for example 
policeman, emergency room personnel, doctor, etc. or may be a combination of both, the 
status code for example beuig encrypted into the ID code. The USR software 18 
determines if the code is valid (1506), accesses the user's information in the USR 
database 24 and transmits available information to the party (1508). In this scenario, the 
user may be provided with a plurality of different codes to enter into the electronic ID 
device depending on the type of information to be released to the party. For example, the 
user's basic code may be 1234. The fifth digit of the electronic code may specify the 
type of information to be provided, i.e., 1= address information, 2=medical information; 
3=telephone information, 4=job application information, etc. Using multiple codes 
eliminates any ambiguity about the authority provided by the user to the party, but 
requires the user to remember additional information. 

The above assumes the user is able to provide an ID code when the information is 
required. However, in for example an emergency room situation, the user may not be in 
a position to provide the ID code, but would still want medical records provided. The 
release authorization for certain portions of the users database could therefore specify that 
the information be released to certain class or classes of individuals and the USR system 
would release such information to individuals or organizations based only on status code . 
Thus, the status code of an emergency room could alone trigger release of medical data. 

Fig. 16 illustrates one embodiment of a method of using the USR database 24 to 
complete a standard application, such as a job application or an application to rent an 
apartment. This embodiment is a specific example of the more generic method of 
enabling a party to retrieve information discussed above with respect to Fig. 1 5. In Fig. 
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16, however, the party may be provided with the opportunity to provide a form to the 
USR software 18, the fields of which may be automatically completed with information 
from the job application information section of the USR database 24. 

As can be seen from the above, many of the users of the USR system are 
5 organizations or agencies such as carriers (post office, UPS, FedEX), communication 
companies, law enforcement organizations, hospitals and other medical facilities and the 
like. Each of these organizations can be provided with specialized software either on a 
disc or other suitable media or electronically, for example over the internet, which 
performs a number of functions, for example automatically generating status codes for 

10 data access requests, controlling information received, and formatting data received in 
response to a request in a desired way. This can result in an access request from such 
organization for a given user causing all data on the user required to complete the form 
being retrieved and presented to the organization in the format of their form. A user may 
also authorize an organization for which a form has been completed using the USR 

1 5 system to receive updates, either in response to a request from the organization or at 
selected intervals, for example once a year, so as to maintain information in the forms 
current. Since the user will be providing information to the system on a regular basis, 
this is a relatively easy and painless way for the user to maintain current information with 
many organizations the user deals with. 

20 Another potential use of the system is to permit a person to be located where only 

limited biographical information on the person is known. Users of the USR system 
wishing to participate in this feature could be cued to provide non-confidential 
biographical data when they come on the system or at any time thereafter when they 
decide to participate. They can also indicate whether they wish their name given out in 

25 response to such an inquiry or to merely be alerted to an inquiry which might involve 

them and information on the requester. A person seeking to find another person or group 
of people can input appropriate biographical data, for example members of 1975 Harvard 
University hockey team, or information of a persons last known address plus school 
information, etc. The system will then provide a list of persons who meet the listed 

30 criteria from which the person making the inquiry can hopefully find the person they are 
looking for. 
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In the above application and others, when a person is located, the person may 
request that only the persons address code or general access code (ie a single code which 
is used to get current address, telephone, e-mail, etc. information) be provided when the 
person is located. This can further protect the individual from undesired contacts. 

Fig. 17 illustrates another embodiment of the invention. As shown in Fig. 17, the 
USR system 10 may be used to secure expensive personal equipment, such as stereos, 
televisions, laptop computers, cellular telephones, cars, boats, and other items of value to 
a person. In this embodiment, each item to be secured using the USR system is provided 
with a USR timer chip imbedded in the electronics. If the USR timer chip is not provided 
with a code within a predefined period of time, for example every 30 days, the equipment 
is deactivated. Thus, for example, a television, mobile phone, laptop computer, 
automobile, heavy equipment, weapon or facility may be provided with a security chip 
having an internal timer that must be reset before expiration by provision of a particular 
code. When reset does not occur, the tuner will disable the electronic device or other 
device using any one of a number of known disablement methods. Exemplary codes may 
be transmitted in the same manner as beeper signals are conventionally transmitted or 
may be transmitted to wired devices over the Internet or other public network. 

The USR system 10 may be advantageously employed to automatically provide 
the secured property with the necessary codes at appropriate intervals, unless instructed 
by the user of the USR system 10 to cease doing so. Ahematively, the USR system 10 
may require participation by the user prior to sending out the activation codes. 

In this embodiment, the user may provide to the USR system 1 0, information 
indicative of the codes to be transmitted, timing information, and automation information 
~ i.e., whether the codes should be sent automatically or should require user intervention. 
Optionally, where the user opts to require user intervention, the USR system 10 may 
notify the user of the upcoming deadline via e-mail or another method. 

This system may be useftil to secure sensitive equipment other than personal 
equipment as well, such as military equipment, public equipment, school equipment and 
any other equipment that is subject to theft. 

It should be understood that various changes and modifications of the 
embodiments shown in the drawings and described in the specification may be made 
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within the spirit and scope of the present invention. Accordingly, it is intended that all 
matter contained in the above description and shown in the accompanying drawings be 
interpreted in an illustrative and not in a limiting sense. The invention is limited only as 
defined in the following claims and the equivalents thereto. 
What is claimed is: 
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